This section is intended to provide a background to the various embodiments of the technology that are described in this disclosure. The description in this section may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not necessarily prior art to the description and/or claims of this disclosure and is therefore not admitted to be prior art by the mere inclusion in this section.
Detailed descriptions of radio communication networks and systems can be found in literature, such as in Technical Specifications published by, e.g., the 3rd Generation Partnership Project (3GPP). 3GPP Long Term Evolution (LTE) is the fourth-generation radio communication technologies standard developed within the 3rd Generation Partnership Project (3GPP) to improve the Universal Mobile Telecommunication System (UMTS) standard to cope with future requirements in terms of improved services such as higher data rates, improved efficiency, and lowered costs. The Universal Terrestrial Radio Access Network (UTRAN) is the radio access network of a UMTS and Evolved UTRAN (E-UTRAN) is the radio access network of an LTE system. In an UTRAN and an E-UTRAN, a user equipment (UE) is wirelessly connected to a Radio Base Station (RBS) commonly referred to as a Node B (NB) in UMTS, and as an evolved NodeB (eNodeB or eNB) in LTE. An RBS is a general term for a radio network node capable of transmitting radio signals to a UE and receiving signals transmitted by a UE. As used in this disclosure, the term “user equipment (UE)” is used to mean any device, which can be used by a user to communicate. Also, the term UE may be referred to as a mobile terminal, a terminal, a user terminal (UT), a wireless terminal, a wireless communication device, a wireless transmit/receive unit (WTRU), a mobile phone, a cell phone, etc. Yet further, the term UE includes MTC (Machine Type Communication) devices, which do not necessarily involve human interaction.
MAC-Level Handshake for Faster and More Robust RRC Synchronized Procedures
The Radio Resource Control (RRC) protocol is responsible for the establishment, maintenance and release of a RRC connection between the UE and the Radio Access Network (RAN) as well as the establishment, reconfiguration and release of Radio Bearers (RBs) and Signaling Radio Bearers (SRBs).
Different RRC procedures (e.g. RB Setup, RB Release and RB Reconfiguration) can be used to reconfigure the RAB parameters, RB/SRB parameters, transport channel parameters and physical channel parameters in the UE from one “source configuration” to another “target configuration”. The reconfiguration is typically triggered by data activity and/or inactivity of existing radio bearers or setup/release of new radio bearers.
For some reconfigurations it may be important that the UE and the network change configuration at exactly the same time. In other words, it may be important that the configuration change at the UE as well as at the network occur essentially at the same time. Otherwise there may be a misalignment between which configurations the UE and the network are using. In turn, this may lead to a situation where the UE and the network cannot communicate with each other any longer. These reconfigurations are typically done using synchronized RRC procedures. FIG. 1 shows an example of a conventional method for synchronized RRC procedures.
As can be seen in FIG. 1, the Radio Network Controller (RNC) initially receives a trigger for a reconfiguration. Thereafter, the RNC sends, i.e. transmits, reconfiguration messages to the UE and the Radio Base Station (RBS) comprising the new configuration. In the reconfiguration messages, an activation time is typically included. The activation time typically specifies the Connection Frame Number (CFN) when the UE and the RBS should switch to the new configuration. The RNC calculates when the UE could be ready to switch to the new configuration and sets the CFN accordingly.
In order to minimize, or at least reduce, the risk of a dropped call due to state misalignment between the UE and the RBS, the RNC generally needs to make sure that the UE will receive the reconfiguration message in time and will switch at the specified CFN. It is therefore customary to estimate the activation CFN very conservatively to take into account UEs that may be in poor radio condition, large possible fluctuations in transport network delay, etc. The result may be a rather long activation time implying that all reconfigurations have to suffer from a long delay that is, in fact, needed only in a few percent of the cases.
The international patent application PCT/SE2014/050010 (published under WO2014/120061A1), filed Jan. 7, 2014, entitled “Changing Radio Bearer Configuration or State”, the entire contents of which is incorporated herein by reference, describes a procedure for fast E-DCH TTI switch. A similar procedure has also been proposed to be used for synchronized RRC procedures in general, see e.g. FIG. 2.
In a procedure like the procedure shown in FIG. 2 no activation time is sent to the UE. Instead, an indication is sent to the UE to activate the new configuration as soon as possible. This is accomplished by means of a MAC-level handshake between the UE and the RBS. When the UE is ready to switch, the UE sends a MAC Control Information to the RBS which then replies with an HS-SCCH order to activate the reconfiguration.
An advantage with this solution is that it is not necessary to choose between a fast reconfiguration and a robust reconfiguration. The procedure generally chooses what is needed for the specific case. In case of good radio conditions the procedure will be faster than if the RNC had calculated the activation time and perhaps added margins for a poorer case. In case of bad radio conditions the procedure may take a bit longer, but the connection will generally not be dropped as it would most likely have been if the RNC had calculated a too tight activation time.
In some cases, e.g., the Fast E-DCH TTI Switch, the RNC may be able to delegate the responsibility of initiating the switch procedure to the UE by pre-configuring the UE with a measurement, a triggering condition, and a target configuration. When the triggering condition is met, the UE would start the handshake procedure by sending a MAC Control Information to the RBS. The UE would then switch to the target configuration at an understood time after having received a reply in the form of an HS-SCCH order from the RBS.
HS-SCCH Orders
The HS-SCCH orders are defined in 3GPP Technical Specification 3GPP TS25.212. Each HS-SCCH order typically comprises the following information:                Extended order type (2 bits) Xeodt,1, Xeodt,2         Order type (3 bits): Xodt,1, Xodt,2, Xodt,3         Order (3 bits): Xord,1, Xord,2, Xord,3         UE identity (16 bits): Xue,1, Xue,2, . . . , Xue,16         
There is a total of 256 HS-SCCH orders divided into 32 types. The current practice is to use one HS-SCCH order for a very specific purpose. Some examples are:                The E-DCH TTI Switch feature uses one HS-SCCH order for the 2 ms→10 ms switch and one for the 10 ms→2 ms switch.        The Continuous Packet Connectivity (CPC) feature reserves 8 HS-SCCH orders, but uses 6 for activation and deactivation of DTX (i.e., discontinuous transmission), DRX (i.e., discontinuous reception) and HS-SCCH-less operation.        The Multi-Carrier features uses over 100 HS-SCCH orders for the activation and deactivation of Secondary serving HS-DSCH cells and Secondary uplink frequency. The large number of HS-SCCH orders used makes it possible to send one HS-SCCH order to activate or deactivate almost any combination of 1 Secondary uplink frequency and 7 downlink Secondary serving HS-DSCH cells.        
To date, there are 4 unused HS-SCCH order types and a total of roughly 50 HS-SCCH orders remaining, which includes unused orders in some of the used types.
MAC Control Information
The signaling of Control Information for E-DCH is defined in 3GPP TS25.321. The scheduling information is used by UEs to indicate to their serving E-DCH Node B (NB) the amount of resources the UEs require and the MAC Control Information is used by UEs to indicate to their serving E-DCH NB additional UL control information.
The general format of the UL MAC control information PDU is FIG. 3, where for each field the LSB is the rightmost bit in the figure and the MSB is the leftmost bit.
The UL MAC control information includes the following common fields:
MTYPE (MessageType): The length of the MTYPE field may be 4 bits. MTYPE indicates the type of Control Information that is transmitted.
DATA: The length of the DATA field may be 10 bits. DATA may carry information, the content of which is dependent on the control information type.
The existing practice of defining one HS-SCCH order for each specific task when applied to MAC-level handshake for synchronized RRC procedures may lead to at least two potential challenges:                1. HS-SCCH orders are limited in number. The potentially large number of synchronized RRC procedures may consume a large fraction of the remaining HS-SCCH orders.        2. It is not obvious from the start which synchronized RRC procedures would benefit from the use of a MAC-level handshake. This may have the consequence that new HS-SCCH orders need to be defined every time when a new procedure suitable for use with the handshake is identified.        
A similar potential challenge generally exists for the MAC Control Information. It may thus be preferable not having to define specific MAC Control information for each type of reconfiguration as there may exist a large number of reconfigurations where a MAC Control Information may be needed.